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Improved secure authenticated channel 



Digital media have become popular carriers for various types of data 
information. Computer software and audio information, for instance, are widely available on 
optical compact disks (CDs) and recently also DVD has gained in distribution share. The CD 
and the DVD utilize a common standard for the digital recording of data, software, images, 

5 and audio. Additional media, such as recordable discs, solid-state memory, and the like, are 
making considerable gains in the software and data distribution market. 

The substantially superior quality of the digital format as compared to the 
analog format renders the former substantially more prone to unauthorized copying and 
pirating, further a digital format is both easier and faster to copy. Copying of a digital data 

0 stream, whether compressed, uncompressed, encrypted or non-encrypted, typically does not 
lead to any appreciable loss of quality in the data. Digital copying thus is essentially 
unlimited in terms of multi-generation copying. Analog data with its signal to noise ratio loss 
with every sequential copy, on the other hand, is naturally limited in terms of multi- 
generation and mass copying. 

5 The advent of the recent popularity in the digital format has also brought about 

a slew of copy protection and DRM systems and methods. These systems and methods use 
technologies such as encryption, watermarking and right descriptions (e.g. rules for accessing 
and copying data). 

One way of protecting content in the form of digital data is to ensure that 
0 content will only be transferred between devices if 

• the receiving device has been authenticated as being a compliant device, and 

• the user of the content has the right to transfer (move and/or copy) that content to 
another device. 

If transfer of content is allowed, this will typically be performed in an encrypted way to make 
5 sure that the content cannot be captured illegally in a useful format from the transport 
channel, such as a bus between a CD-ROM drive and a personal computer (host). 

Technology to perform device authentication and encrypted content transfer is 
available and is called a secure authenticated channel (SAC). In many cases, a SAC is set up 
using an Authentication and Key Exchange (AKE) protocol that is based on public key 
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2. Zero Knowledge Protocols, such as those by Fiat-Shamir, Guillou-Quisquater, and 
Schnorr, are also only supported on bi-directional channels, and 

3. broadcast encryption, which works on both uni-directional and bi-directional 
channels. 

In a broadcast encryption protocol, authentication is usually closely linked 
with transfer of the content decryption key. For this purpose, each participant has a unique set 
of cryptographic keys. Here, these keys are referred to as secret keys. Individual secret keys 
may be in included in the sets of many participants. The publisher creates a message that 
contains the content decryption key. This message is encrypted using the secret keys in such 
a way that only a subset of all participants can decrypt the content key. Participants that can 
decrypt the content key are implicitly authenticated. Participants that are not in the subset, 
and thus cannot decrypt the content key, are revoked. 

E.g. for the uni-directional channel from the publisher to the player, one can 
use a broadcast encryption technology that is based on a hierarchical tree of cryptographic 
keys. The broadcast message is called the EKB. The decryption key contained in the EKB is 
called the Root Key. For more information, see 

° D.M.Wallner, E. LHarder, and R.C. Agee, "Key Management for Multicast: Issues 

and Architectures," Request For Comments 2627, June 1999. 
° C.K. Wong, M. Gouda, and S. Lam, "Secure Group Communications Using Key 
Graphs," Proceedings SIG-COMM 1998, ACM Press, New York, pp. 68-79. 
We will now discuss these 3 types of authentication and their 
advantages/disadvantages. 

Public key pmtocoB 

The following notation will be adhered to in this document: 
° Px => the public key belonging to X 
° Sx => the private key belonging to X 

° C= E[KjM\ => ciphertext C is the result of encrypting message M with key K 
o M> = D[K, C] => plaintext AT is the result of decrypting C with key K. 
o Cert a = Sign[6fe*4] => Certificate Cert A is the result of signing message A with private 
key& 
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Challenge / Response based Public Key Protocol 
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A variant of this protocol is one where B sends the random number r 
encrypted with A-s public key. A then demonstrates knowledge of his secrot key by 
decrypting the received number r and returning it to B. 
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wrm md fbrwarfs it to B. B can decrypt ft ^ 
common key. 
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It is clear that at the very least the protocol requires one private key operation 
from both parties, and peihaps 2 or more depending on the exact bus-key establishment 
protocol. 

Zero Knowledge (Guillou-Quisquater) based Public Key Protocol 

In a Guillou-Quisquater (GQ) based Public Key protocol, a user A desires to authenticate 

him/herself to user B. To that end A has received from the Licensing Authority (LA) the 
following: 

• a public-private key-pair {J A , s A } (the LA also selects a public exponent v and a 
modulus N 9 which defines the finite field in which are calculations are done. For 
brevity we omit further reference to this parameter) 

• a certificate Cert A = Sign[SiA , A\\Jj\, where Su is the private key of the LA 
All users (A and B) receive: 

• the public key of the licensing authority Pla 

• v, the public exponent and security parameter, v is typically 2 16 or 2 20 . 
The protocol is outlined in Figure 3. It works as follows. 

1 . A generates a random number r, and computes T=r v mod N. A identifies himself to 
B by providing his identifier, here the serial number A, his public key J A , his 
certificate from the LA and T m 

2. B verifies the public key and identity of A from the certificate, using the public key of 
the LA, Pla . If required, B checks that A and J A are not revoked: i.e. they appear on a 
whitelist or alternatively do not appear on a blacklist If true, B proceeds by 
generating a random number d from {1,. . .,v-l }, and sends it to A. 

3 . A responds by constructing D = r- (s A ) d mod N, and returns the result to B . 

4. Using A's public key J A , B verifies that (J A ) d - (D) v = Tmod N. If correct, A has 
proven that he knows s A with probability 1 : v., i.e. with higji likelihood he is A. 

To achieve mutual authentication, the protocol can be repeated with the 
entities performing the steps reversed. The steps can also be interchanged, e.g. first step 1 
with A providing his identifier to B, then step 1 with B providing his identifier to A, and 
similarly for the other steps. Variants of this protocol are the (Feige-)Fiat-Shamir and Schnorr 
zero-knowledge protocols. 

This protocol is much cheaper than challenge-response cryptography, because 
the expensive exponentiations always involve a relatively small power (3 to 5 digits, instead 
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Kroou Now software is often hacked, and this means Kroot could be extracted from the 
software and published on a web-site, allowing a hacker to set up to authenticate 
successfully. Such software is hard to revoke, because no device keys are published in the 
attack. 

After a few devices have been hacked and their device keys retrieved, hackers 
can start making their own (newer) EKBs thus turning once revoked devices back into non- 
revoked devices. To counter this, EKBs are often signed with the private key of the LA, so 
that tampering can be immediately detected. 

It is an object of the invention to introduce a method of establishing a secure 
authenticated channel which avoids the disadvantages of public key authentication (high 
cost), EKB (leakage of K root in the host) and Zero Knowledge (no shared secret). 

According to the invention, a first device (preferably a peripheral device) 
authenticates a second device (preferably a host computer) using a public key protocol. 
However, the second device authenticates the first device using an EKB based protocol in 
combination with a Zero-Knowledge protocol such as Guillou-Quisquater. 

Figure 5 schematically shows a preferred embodiment of the invention, by 
way of example showing authentication between a host computer and a peripheral device. An 
advantage of this embodiment is that the host computer does not require access to a set of 
secret keys. Instead, the host computer verifies that the peripheral device can decode the EKB 
(knowledge of Kroot) using the Guillou-Quisquater zero -knowledge protocol. Actually the 
peripheral device proves knowledge of Kroot because it can decrypt the GQ-private key 
which is stored encrypted with Kroot in the EKB. Consequently, the operations that the 
peripheral device has to perform according to this protocol require a computation power that 
is about equal to the public key operations of the Sapphire public key protocol. 

The protocol according to this embodiment consists of five steps: 

1 . In the first step, the peripheral device sends the host computer a random number s as 
well as an EKB (EKB device ) m The peripheral device obtains EKB device from, e.g., an 
optical disc and claims that it can decode this EKB. 

2. In the second step, the host computer sends the peripheral device its Certificate, 
Certhosh a signed copy of s, and (optionally) an EKB (EKBhost)* The Certificate 
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In order to best support the proposed protocol, either the EKB format has to be 
modified, or an additional data structure must be defined Figure 6 shows the first option, the 
EKB format in combination with a zero -knowledge data structure. Basically, the zero- 
knowledge data structure contains an EKB verification data field, which creates a link to the 
associated EKB. Note that this field replaces the functionality of the authentication data field 
in the EKB. The other two fields contain the Guillou-Quisquater "public" and "private 
keys." The "private key" is encrypted using the Root Key of the EKB. 

Figure 7 shows the format of an enhanced EKB according to the second 
option. Here, the "public key 9 ' is added to the key check data field, which is encrypted using 
the Root Key. The "private key" is added to the authentication data field, which is signed by 
the TTP. 

To summarize: to prevent copying of content on interfaces, a secure 
authenticated channel (SAC) must be set up. Traditional methods for authentication include 

(i) Challenge/Response Public Key Protocols, 

(ii) Zero knowledge-protocols, and 

(iii) broadcast encryption protocols. 

Protocol (i) is very burdensome for low-cost peripherals, (ii) does not support 
key-exchange, and (iii) is subject to catastrophic system-failure after single key-leakage in a 
software environment. These protocols are usually applied symmetrically. 

To mitigate all these problems, the invention proposes an asymmetric 
authentication protocol where a first device (e.g. a PC) authenticates itself using (i) and a 
second device authenticates itself using a combination of (ii) and (iii), where preferably the 
secret of (ii) is scrambled and cryptographically bound to the key-block in (iii). 

Of course the devices do not have to be personal computers and CD-ROM 
drives. Any device that is required to authenticate another device and/or to authenticate itself 
to that other device can benefit from the present invention. The content can be distributed on 
any medium or via any transport channel. For example, the content can be distributed on 
flash media or over a USB cable. 

The device transmitting or receiving the content over the SAC may perform 
checks to see whether transmitting or receiving is permitted. For example, the content may 
have a watermark that indicates no copies may be made. In such a case transmission or 
reception should be blocked even if a SAC was successfully set up. 

The devices could be part of a so-called authorized domain in which more 
liberal copying rules may apply. In authorized domains also SACs are commonly used to 
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estabhsh seem* content tomsfer between *, members rf ^ ^ for 

International patent appbcation serial number PCT/1B02/04803 (attorney docket 
^ZT, aDiEa mPeaDPaieM ^^ dumber 02076998.0 (attorney docW 

- — — - -rasauH asOTBfi&iKSK^^ 

1mm the invention, and that those skilled in the art will be able to design many alternative 
embodiments without departing torn the scope of me appended claims. The invention is 
preferably implemented using software rtmning on the respective devices and arranged to 
execute the protocol according to toe invention. To this end the devices may comprise a 
processor and a memory to store the software. Secure hardware tor e.g. storing cryptographic 

course the invention can also be implemented using special chantry, or a combination of ' 
dedicated circuitry and software. 

In the claims, any reference signs placed between parentheses shall not be 
construed as limiting fee claim The word "comprising" does not exclude the presence of 
elements or steps other than those listed in a claim. The word "a" or "an" preceding an 
element does not exclude the presence of a plurality of such elements. The invention can be 

T""* 1 ** *" 1 5555 elemente, and by means of a 

suitably programmed computer. 

In the system claim enumerating several means, several of these means can be 
embodied by one and the same hem of hardware. The mere feet ma, certain measures are 
recited in mutually different dependent claims does no, indicate ft* a combination of these 
measures cannot be used to advantage. 
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CLAIMS: 



1 . A method of establishing a secure authenticated channel between two parties 

A and B, where A authenticates to B using challenge/response public key cryptography, and 
B authenticates to A using a zero-knowledge protocol. 

5 2. The method of claim 1 , in which the zero-knowledge protocol is a Guillou- 

Quisquater zero-knowledge protocol. 

3. The method of claim 1, in which the zero-knowledge protocol is a Fiat-Shamir 
zero-knowledge protocol. 

0 

4. The method of claim 1 , in which the zero-knowledge protocol is a Schnorr 
zero-knowledge protocol. 

5. The method of claim 1, in which B authenticates to A using a combination of 
5 the zero-knowledge protocol and a broadcast-encryption system, where a secret used in the 

zero-knowledge protocol is scrambled such that it can only be obtained by those that can 
process a broadcast encryption key-block successfully. 

6. The method of claim 5, where the secret used in the zero-knowledge protocol 
0 is encrypted by the root-key Kroot of a broadcast encryption system key-block. 

! 7. The method of claim 5, where there is one EKB with a root key Kroou to allow 

for authentication, and another EKB with root key Kroota for content encryption. 

5 8. The method of claim 1 or 5, where the zero -knowledge pair {J,s} is different 

| for every key-block. 

9. A system comprising a first device A and a second device B, where the device 

A is arranged to authenticate to the device B using challenge/response public key 
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cryptography, and the device B is arranged to authenticate to the device A using a zero- 
knowledge protocol. 



T0 ' _ A ^ device A arranged to authenticate itself to a second device B using 

B using a zero-knowledge protocol. 

11. A second device B arranged to authenticate itself to a first device A using a 
zero- knowledge protocol, and arranged to authenticate the first device A using 

10 challenge/response public key cryptography. 

12. A computer program product comprising code enabling aprogrammable 
device to operate as the first device of claim 10 and/or the second device of claim 11. 
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To prevent copying of content on interfaces, a secure authenticated channel 
(SAC) must be set up. Traditional methods for authentication include (i) Challenge/Response 
Public Key Protocols, (ii) Zero knowledge-protocols, and (iii) broadcast encryption 
protocols. Protocol (i) is very burdensome for low-cost peripherals, (ii) does not support key- 

5 exchange, and (iii) is subject to catastrophic system-failure after single key-leakage in a 
software environment. These protocols are usually applied symmetrically. The invention 
proposes an asymmetric authentication protocol where a first device (e.g. a PC) authenticates I 
itself using (i) and a second device authenticates itself using a combination of (ii) and (iii), 
where preferably the secret of (ii) is scrambled and cryptographically bound to the key-block 

3 in (iii). 
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